Automotive Ethernet · SOME/IP-SD · Vector CANoe

SOME/IP with ANDi & Vector

This page documents a four-part automotive connectivity lab conducted at Deggendorf Institute of Technology. The work covered OSI layers 1 to 4 through physical network setup, raw Ethernet scripting, VLAN based gateway configuration, and SOME/IP / SOME/IP-SD traffic analysis with ANDi, Vector CANoe, a Technica MediaGateway, and a Vector VN5610 interface.

View References →

Overview

SOME/IP provides service-oriented communication for automotive ECUs through RPC-style calls, event notifications, and a defined wire format. Service discovery and subscription handling are managed by SOME/IP-SD. In this lab, CAMF acted as a camera service provider, while ADAS searched for the service, subscribed to the event group, and received cyclic notification traffic.

The lab used a Technica MediaGateway, a Vector VN5610 hardware interface, Vector CANoe for virtual ECU simulation, and ANDi for traffic viewing and script-based frame generation. The final experiment tried to imitate selected CAMF SOME/IP-SD messages from computer 2 after the original CAMF simulation was deactivated. The reproduced traffic was visible in CANoe, but the Offer Service and Subscribe Eventgroup Acknowledgment messages were not fully separated in the final script.

Lab Structure

Part IDevices, IP/MAC, ANDi loopback
Part IITransmit/Receive scripts, VLAN
Part IIIMulti-gateway interconnection
Part IVSOME/IP with VN5610 & Vector

Key Concepts and Lab Findings

1. OSI Model and automotive networking scope+

The lab focused on OSI layer 1 to layer 4. It covered physical automotive Ethernet links, Ethernet frame handling, IP-level addressing, transport-level traffic, and selected service-oriented SOME/IP behaviour.

Technical detail

OSI Physical Layer   →  BroadR-Reach / 100BASE-T1
OSI Data Link Layer  →  Ethernet frames, VLAN tagging
OSI Network Layer    →  IPv4 addressing, ARP
OSI Transport Layer  →  UDP / TCP (used by SOME/IP)

Each section of the lab targeted a different layer combination. This scope helped connect physical setup issues with packet level behaviour and service discovery results.

2. SOME/IP protocol – scalable service-oriented middleware+

SOME/IP (Scalable service-Oriented MiddlewarE over IP) was developed to enable dynamic, service-oriented communication between ECUs with different sizes and operating systems. Compared with classical CAN-based signal communication, SOME/IP supports a more dynamic service-oriented model over Ethernet with remote procedure calls, event notifications, and a defined serialisation format over UDP or TCP.

Technical detail

SOME/IP message structure:
  Message ID   [32 bit]  – Service ID + Method ID
  Length       [32 bit]  – from Request ID to end
  Request ID   [32 bit]  – Client ID + Session ID
  Protocol Ver  [8 bit]
  Interface Ver [8 bit]
  Message Type  [8 bit]  – REQUEST / NOTIFICATION / RESPONSE / ERROR
  Return Code   [8 bit]
  Payload       [variable]

UDP payload limit: 0–1400 bytes
TCP: segmentation supported, larger payloads allowed

The Message ID identifies the service and method or event within the system. The Request ID helps providers and subscribers track parallel uses of the same method or event.

3. SOME/IP service model – events, methods, and fields+

SOME/IP structures communication through service definitions. A service can combine events, methods, and fields. Events carry data periodically or on change, from provider to subscriber. Methods allow subscribers to trigger remote procedure calls on the provider side. Fields combine notifiers, getters, and setters – notifiers send data on subscription and on change, getters let subscribers request current values, and setters allow subscribers to modify provider-side values.

In the lab simulation, CAMF acted as the service provider and ADAS as the subscriber. SOME/IP transported service data, while SOME/IP-SD handled discovery, offer, subscription, and acknowledgment behaviour.

4. SOME/IP-SD – service discovery mechanism+

SOME/IP-SD (Service Discovery) handles the publishing and subscription side of SOME/IP. It implements a Publish/Subscribe concept: the server publishes its service, and the client subscribes to it. SOME/IP itself only transports the updated values; the discovery and subscription lifecycle is managed by SOME/IP-SD. In the lab, the communication sequence followed a strict order across the same Session ID.

Technical detail

ADAS  →  SOME/IP-SD: Find Service
CAMF  →  SOME/IP-SD: Offer Service
ADAS  →  SOME/IP-SD: Subscribe Eventgroup
CAMF  →  SOME/IP-SD: Subscribe Eventgroup Acknowledgment

After acknowledgment, the cycle repeats with cyclic NOTIFICATION updates.

When CAMF was deactivated in the lab, ADAS kept sending Find Service messages repeatedly because no Offer Service reply arrived. This confirmed that the service discovery handshake must complete before event data can flow.

5. BroadR-Reach and 100BASE-T1 physical layer+

BroadR-Reach (standardised as 100BASE-T1 in IEEE 802.3) is an automotive Ethernet physical layer that achieves 100 Mbit/s full-duplex communication over a single unshielded twisted copper pair. It reduces cable weight and cost compared to standard Ethernet while preserving compatibility with the Ethernet MAC layer. The physical layer uses PAM3 modulation at 33.3 MHz bandwidth to minimise EMI.

Technical detail

100BASE-T1 key properties:
  Speed:          100 Mbit/s full duplex
  Cable:          1 unshielded twisted pair
  Modulation:     PAM3 (33.3 MHz bandwidth)
  Standard:       IEEE 802.3bw
  Application:    In-vehicle Ethernet backbone

The MediaConverters in the lab converted standard Ethernet from the PCs into 100BASE-T1 to approximate an automotive Ethernet lab topology between virtual ECUs and gateway hardware.

6. VLAN tagging and traffic segmentation+

A VLAN (Virtual Local Area Network) segments working groups at OSI layer 2 by adding tag information to Ethernet frames. In the MediaGateway, VLAN mode is activated globally and each port is assigned a default VLAN ID. Frames are forwarded only to ports sharing the same VLAN ID, which improves bandwidth efficiency and adds a security layer by filtering frames with unknown VLAN tags.

Technical detail

VLAN tag structure (802.1Q):
  TPID   [16 bit] – Tag Protocol Identifier (0x8100)
  PCP    [ 3 bit] – Priority Code Point
  DEI    [ 1 bit] – Drop Eligible Indicator
  VID    [12 bit] – VLAN Identifier (0–4094)

Example configuration in lab:
  BR-S1-P3  →  VLAN ID 040  (BroadR-Reach port)
  S1-P5     →  VLAN ID 049  (Ethernet port)

In Part III, all ports on the path to the Central WebCam (S1-P3 → S1-P8 → S2-P4 → S2-P8 → S3-P4 → S3-P8) had to be tagged with VLAN ID 073 to allow traffic to traverse the Central MediaGateway.

7. ANDi tool – scripting and traffic analysis+

ANDi (Automotive Network Diagnoser) is a test and simulation environment for Ethernet ECUs and bus systems (CAN, LIN, FlexRay). Scripting in ANDi uses a Python-based language with proprietary library functions. Adapters are configured as Stimulation (transmit) or Logging (receive). The tool supports live traffic viewing, PCAP replay, and direct SOME/IP frame generation through its Traffic Generator.

Technical detail

ANDi script structure (simplified):
  g_ethernet_msg.mac_address_source      = source_mac
  g_ethernet_msg.mac_address_destination = dest_mac
  g_ethernet_msg.payload = System.Array[Byte](...)
  g_ethernet_msg.send()
  sleep(1)   # timed transmission loop

The ANDi Traffic Generator was used in Part IV to imitate selected CAMF behaviour from computer 2. The reproduced traffic appeared in CANoe, but the acknowledgment behaviour was not cleanly separated from the Offer Service message.

8. Vector VN5610 and CANoe integration+

The Vector VN5610 is an Ethernet/CAN/USB interface used as a Vector Network Interface (VNI). It supports 10BASE-T, 100BASE-T1, 100BASE-TX, and 1000BASE-T physical layers, as well as CAN and LIN. In the lab, it connected computer 1 to the MediaGateway via 100BASE-T1 BroadR-Reach. CANoe used it to simulate two virtual ECUs: CAMF (camera) and ADAS (Advanced Driver-Assistance Systems).

Technical detail

VN5610 connections in lab:
  CH1  →  MediaGateway S3-P3 via BroadR-Reach
  CH2  →  not used (redundant for this project)
  USB  →  Computer 1 (CANoe host)

CANoe project loaded: SOMEIPBasicAutosar
Ethernet channel setting: IEEE 100BASE-T1 (BR), Master (DSUB9)
MediaGateway BroadR-Reach port mode: Slave
Traffic observation path: VN5610 / CANoe host → MediaGateway → Computer 2 / ANDi

No extra IP configuration was needed for the VN5610 because it acts as an interface rather than a network endpoint. The ECU IP addresses are managed within the CANoe simulation.

9. CAN and LIN bus protocols+

CAN (Controller Area Network) is a message-based protocol standardised under ISO 11898. It serialises data frames from multiple ECUs and grants transmission priority to the highest-priority device when collisions occur. It performs CRC-based error checking and nodes can disconnect if error counts exceed a threshold. LIN (Local Interconnect Network) complements CAN for simpler, lower-bandwidth subsystems where a single master controls up to 15 slaves over one wire.

Technical detail

CAN priority arbitration:
  Higher priority ID wins bus access
  Error detection via CRC
  Node states: Error Active → Error Passive → Bus Off

LIN topology:
  1 master + up to 15 slaves
  Single wire serial protocol
  Lower bandwidth than CAN – used as helper protocol

In the lab, a CAN-Motor module was connected to the MediaGateway via CAN-A, and a CANcaseXL on computer 2 accessed it. This allowed CAN data to reach the Ethernet-based system through the gateway.

10. Lab result – imitating CAMF with ANDi+

The final goal of Part IV was to reproduce selected CAMF SOME/IP-SD behaviour from computer 2 using ANDi scripts. The script was based on captured Wireshark and ANDi traffic. Service ID, Instance ID, Eventgroup ID, TTL, version information, and SD entry structure were investigated. The reproduced frames appeared in CANoe as Offer Service traffic, but the final implementation did not cleanly separate the expected acknowledgment behaviour.

The Acknowledge message was not fully separated from the Offer Service in the final result, likely due to incomplete if-condition logic in the ANDi script. The project identified this as a limitation related to insufficient documentation for this specific SOME/IP-SD scripting pattern.

Tools Used

  • ANDi (Automotive Network Diagnoser) – scripting and traffic viewer
  • Vector CANoe – ECU simulation and trace analysis
  • Vector VN5610 – Ethernet/CAN/USB hardware interface
  • Technica Engineering MediaGateway – automotive Ethernet switch
  • Wireshark – packet capture and SOME/IP-SD inspection
  • Zenmap / Nmap – port scanning and host discovery

Key Challenges

  • Limited ANDi documentation made SOME/IP-SD scripting difficult.
  • Understanding VLAN path configuration across three switch layers.
  • Separating Offer Service and Acknowledge messages in the reproduced script.
  • Both tools (ANDi and CANoe) required valid licences to operate.
  • Finding the correct camera port using Zenmap required knowledge of standard TCP/UDP port numbers.

References and Materials

These sources were used for the SOME/IP protocol specification, BroadR-Reach physical layer, ANDi scripting, Vector hardware, and general automotive networking background.